home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Columbia Kermit
/
kermit.zip
/
newsgroups
/
misc.19980424-19980901
/
000139_news@newsmaster….columbia.edu _Wed May 27 12:10:45 1998.msg
< prev
next >
Wrap
Internet Message Format
|
2020-01-01
|
7KB
Return-Path: <news@newsmaster.cc.columbia.edu>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id MAA13256
for <kermit.misc@watsun.cc.columbia.edu>; Wed, 27 May 1998 12:10:44 -0400 (EDT)
Received: (from news@localhost)
by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id MAA11150
for kermit.misc@watsun; Wed, 27 May 1998 12:10:44 -0400 (EDT)
Path: news.columbia.edu!newsfeed.nyu.edu!news.idt.net!cpk-news-hub1.bbnplanet.com!news.bbnplanet.com!europa.clark.net!128.158.254.10!news.msfc.nasa.gov!info.usuhs.mil!news.monroe.army.mil!wrdiss1.robins.af.mil!wpdiss1.wpafb.af.mil!oodiss1.hill.af.mil!news.cc.utah.edu!not-for-mail
From: kirkland@ee.utah.edu (Dan Kirkland)
Newsgroups: comp.protocols.kermit.misc,comp.sys.hp48
Subject: Re: Kermit on the HP48 (Was: One-Way Transfer)
Date: 27 May 1998 08:55:57 -0600
Organization: Univ of Utah Electrical Engineering Dept
Lines: 141
Message-ID: <6kh9ht$14i@ee.utah.edu>
References: <6k42pd$a3m$1@apakabar.cc.columbia.edu> <wk67iy1b8j.fsf@jhuapl.edu> <6k4ef6$g6p$1@apakabar.cc.columbia.edu>
NNTP-Posting-Host: ee.utah.edu
Xref: news.columbia.edu comp.protocols.kermit.misc:8802 comp.sys.hp48:81500
Sorry for joining this a bit late, but I don't read news real
often. And the university's news feed seems to be screwy, so
many articles are very late (so my replies may be out of order).
[very many deletions]
In article <6k4ef6$g6p$1@apakabar.cc.columbia.edu>,
fdc@watsun.cc.columbia.edu (Frank da Cruz) writes:
>In article <wk67iy1b8j.fsf@jhuapl.edu>,
>Skip Collins <collibf1@jhuapl.edu> wrote:
>: fdc@watsun.cc.columbia.edu (Frank da Cruz) writes:
>: > But we usually find that what works for us fails to work for others, or
>: > vice versa. No doubt because there are many and varied HP-48 models, ROM
>: > versions, etc etc.
>: > 2. Should the flow control setting be NONE or XON/XOFF? We have
>: > conflicting reports (see above). Obviously the HP-48 *should* be
>: > exercising some form of flow control, but some reports indicate that
>: > it does not (even if it is set to do so).
>:
>: Why is flow control necessary or even desirable given the maximum
>: packet size is 94 and the receive buffer is 255?
>:
>Theoretically, it would not be necessary. But I don't know how their
>Kermit implementation works internally. Does it parse incoming packets as
>it reads them, or does it read them first and then parse them? Can anything
>else happen during a read? Garbage collection, etc?
Flow control is dependant on BOTH sides, is it not?
The HP48 should not need flow control for itself, but it sometimes
may be needed to work with the OTHER computer (right?).
I have never used XON/XOFF with MSKERMIT or C-Kermit on HP-UX.
Someone did tell me that they needed XON/XOFF for transfers with
C-Kermit on a PC with Linux. (???)
>: > 3. Is the link transparent to incoming control characters? Can the
>: > client Kermit program use control-character unprefixing when sending
>: > to the HP-48? If not, the client program must be told to
>: > SET CONTROL PREFIX ALL prior to sending files to the HP-48.
>:
>: Shouldn't control char unprefixing be a negotiated feature?
>:
>It would seem so, but no. The reason is that the two parties have no idea
>what lies between them, and so there is no way they can negotiate a safe
>set of control characters.
>
>: If it is not, I can see where this might be the cause of many people's
>: problems. Surely it is not the default?
>:
>Most Kermit programs prefix all control characters by default when sending a
>file. Kermit 95 is the exception, since most Windows 95 users demand "high
>performance". Kermit 95's default is to unprefix a fairly safe subset of
>control characters.
Sadly, the HP48 REQUIRES control character prefixing.
All characters less than character 32, characters 127 to 159, and
character 255, ALL MUST BE PREFIXED!
If ANY of these characters (0-31, 127-159, 255) are NOT prefixed,
it just will NOT work! (Sad huh?)
>: > The HP communication port is half duplex, meaning that data can go in both
>: > directions, but only in one direction at a time. Therefore sliding
>: > windows can not be used (this too should be negotiated automatically).
>:
>: The serial port is full duplex. The infrared port is only half-duplex
>: because of optical feedback.
>:
>Does this apply to all models? I got my information about dead periods in
>the serial port from an HP engineer, circa 1990.
The HP48 kermit commands are designed to work with half-duplex.
Dead periods???
The poorly written HP48 commands will surely CREATE dead periods
such as between packet receiving and acknowledgement (and likely
others...).
>: > Postings on comp.sys.hp48 indicate that the HP-48 Kermit implementation
>: > "parses" incoming text-mode material on the fly, and appends the material
>: > from each incoming packet to a "string", resulting in a steadily
>: > deteriorating transfer rate, at least up to some point at which the HP-48
>: > dumps the string to storage and starts over with a new string. There's
>: > not much that the Kermit client can do about that.
>:
>: This is the biggest problem with hp48 kermit.
>:
>Can you help clear this up? What is the deal? Text-mode transfers into
>the HP-48 are the ones that get progressively slower? But binary-mode
>transfers into the HP-48 are OK?
Okay, yes text-mode material is parsed on-the-fly.
But, ALL HP48 kermit transfers get progressively slower!
That right! BOTH text AND binary transfers get slower and slower!
>Is it true that incoming text-mode packets are parsed as HP-48 programs?
>So this means that only HP-48 programs may be sent in text mode, and any
>other text files sent to the HP-48 are likely to be rejected. One user
>reported that any text file containing a "-" character would be rejected
>for "Invalid syntax".
>
>This means that non-HP-48-program files must be sent to the HP-48 in binary
>mode, right?
No, this is not quite right.
Yes text-mode packets are parsed..., into a HP48 user OBJECT!!!
It could be parsed into a program, or a list, or a string, or ...
For non-HP48 objects you just need to add a string header (C$ $ )
before sending and it will be parsed into a string.
One more thing...
It seems to me that ASCII mode on the HP48 is an HP48 mode and
NOT a kermit mode! (???)
Meaning files can pretty much always be sent to the HP48 as binary
files, then the HP48 will decide how to decode the file.
(It seems that the HP48 always sends starting with an F packet,
and when it receives it expects to start with either an F or an
X packet...??? Okay, I'm lost here...)
Hope this helps,
dan